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(54) Internet multimedia broadcast system 

(57) A method and system for playback of live and 
pre-recorded multimedia data in real-time over a large 
scale communication network, such as the world-wide 
web. The invention allows a user connected to a spe- 
cialized network to play back a multimedia broadcast. 
The invention includes a process that allows multimedia 
content to be created and scheduled as a playlist. The 
playlist data is compressed and transmitted to a host 
system as part of a capture protocol. The captured play- 
list data may then be "broadcast" to users. A user may 
choose a channel selection from a playlist, and cause 
the selected item to be downloaded and played back by 
means of a playback tool. The host system includes a 



highly efficient distribution system that allows a large 
number of users accessing the host through Terminal 
Information Handlers to rapidly access one or more 
channels of multimedia data. The system architecture 
provides a "fan out" mechanism that includes a master 
broadcast process that accepts a multi-stream data flow 
and then distributes the multi-stream data flow to essen- 
tially every Terminal Information Handler accessible to 
the host. The load of providing data streams is thus 
spread among a large number of Terminal Information 
Handlers, reducing access latency and providing sup- 
port for hundreds of thousands of users over a large 
scale communication network. 
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Description 
TECHNICAL FIELD 

[0001] This invention relates to a method and system 
for playback of live and pre-recorded multimedia data in 
real-time over a large scale communication network, 
such as the world-wide web. 

BACKGROUND 

[0002] The world wide web, or Internet, is a large 
scale communication network that has become increas- 
ingly popular with users for accessing data from a huge 
variety of sources. Currently a large percentage of us- 
ers access the Internet through modems, typically hav- 
ing a data rate between about 33.6 Kbps and 1 4.4 Kbps. 
For data such as text or simple graphics, such speeds 
are adequate to enable a "web browsing" experience 
that most users find enjoyable. These data rates are al- 
so acceptable for transmittal and playback of multimedia 
data (e.g., audio, video, still images, text, hyperlinks, 
etc.) in real-time if the data is highly compressed. Ac- 
cordingly, a number of schemes have been implement- 
ed for allowing users to access and download com- 
pressed multimedia data streams for local decompres- 
sion and playback. 

[0003] One such approach for real-time multimedia 
data playback utilizes the Internet multicast protocol. 
Multicasting includes transmitting a communication 
from one site to a group of selected receivers (multicast- 
ing differs from broadcasting in that a broadcast is sent 
to everyone who has the equipment or connection to re- 
ceive it). Under this scheme, a user initiates an action 
(e.g., selection of a uniform resource locator - URL - ad- 
dress) that requests that a multimedia data stream be 
transmitted from a server to the user's client system, for 
decompression and playback by a software process ex- 
ecuting on the client. The request causes the router to 
which the user is coupled to access special multicast 
Internet addresses. The requested data is then supplied 
to the user (or "subscriber") by means of a multicasting 
backbone (MBone), which is a network of special Inte- 
rnet sites that supports Internet Protocol multicasting for 
a limited number of users. MBone provides a faster tech- 
nology than the Internet for transmitting real-time audio 
and video programs. 

[0004] A disadvantage of Internet multicasting is that 
a multicast event (e.g., a live radio show) can only ef- 
fectively support several hundreds to a few thousands 
of users with uninterrupted data streams. Due to band- 
width constraints and the lack of guaranteed quality of 
service for the Internet, adding more users may cause 
objectionable pauses in content {e.g., pauses in multi- 
media playback). Thus, for some events, Internet mul- 
ticasting cannot meet user demand. 
[0005] Accordingly, there is a need for an architecture 
that can provide for playback of live and pre-recorded 



multimedia data in real-time over a large scale commu- 
nication network, such as the world-wide web, for a large 
number of users, typically in the hundreds of thousands 
of users. The present invention provides a method and 
5 system for such an architecture. 

SUMMARY 

[0006] The preferred embodiment of the invention al- 
lows a user connected to a specialized network having 
a "Multimedia Broadcast" feature to play back a multi- 
media broadcast. One aspect of the invention includes 
a Studio Console Process executing on a content pro- 
vider client system that allows multimedia content to be 
created and scheduled as a "playlist". The data compris- 
ing a playlist may be pre-recorded or live. The playlist 
data is compressed under the control of the Studio Con- 
sole Process and transmitted to a host system as part 
of a "capture" protocol controlled by a "radio IN" proc- 
ess. The captured playlist data may then be "broadcast" 
to users who "tune in" to a "live multimedia show", or 
stored for later broadcast. (In this context, "broadcast" 
simply means transmittal of a data stream to a user who 
selects content to be played back on the user's client 
system). 

[0007] A user may choose a "channel" selection from 
a playlist, and cause the selected item to be downloaded 
and played back by means of a "playbacktool". The data 
stream corresponding to the selected item optionally 
may include embedded non-audio content, such as hy- 
pertext links to other forms, URLs to web pages, static 
images, video images, etc. 

[0008] The host system includes a highly efficient dis- 
tribution system that allows a large number of users ac- 
cessing the host through Terminal Information Handlers 
to rapidly access one or more channels of audio data 
augmented by non-audio multimedia data. In particular, 
the inventive system architecture provides a "fan out" 
mechanism that includes a master broadcast process 
that accepts a multi-stream data flow from a "radio OUT" 
process and then distributes the multi-stream data flow 
to essentially every Terminal Information Handler ac- 
cessible to the host. The load of providing data streams 
is thus spread among a large number of Terminal Infor- 
mation Handlers, reducing access latency to typically 
less than about 3 seconds, and providing support for 
hundreds of thousands of users over a large scale com- 
munication network such as the world-wide web. 
[0009] In particular, in one aspect the invention in- 
cludes a system for playback of live and pre-recorded 
multimedia data in real-time over a large scale commu- 
nication network, including a computer system having a 
plurality of terminal information handlers for managing 
general information flow to and from a plurality of users; 
an output process for assembling multiple multimedia 
data streams for distribution; at least one broadcast 
process, in communication with the output process, for 
distributing the assembled multiple multimedia data 



15 



20 



25 



30 



35 



40 



45 



50 



2 



3 

streams to each of the terminal information handlers; 
and a selector process, in communication with the ter- 
minal information handlers, for receiving a channel re- 
quest from a user through an terminal information han- 
dler associated with the user, mapping the channel re- 5 
quest to a corresponding one of the multiple multimedia 
data streams, and enabling transmission of the corre- 
sponding one multimedia data stream to the user 
through the associated terminal information handler. In 
another aspect, the invention includes a corresponding 10 
method. 

[0010] The details of one or more embodiments of the 
invention are set forth in the accompanying drawings 
and the description below. Other features, objects, and 
advantages of the invention will be apparent from the ?5 
description and drawings, and from the claims. 

DESCRIPTION OF DRAWINGS 

[0011] FIG. 1 A is block diagram of the preferred em- 20 
bodiment of the invention. 

[0012] FIG. 1 B is block diagram of a portion of an al- 
ternative embodiment of the invention. 
[0013] FIG. 2 is a "screen shot" of one embodiment 
of a graphical user interface (GUI) for defining a data 25 
stream within a studio console process in accordance 
with the invention. 

[0014] FIG. 3 is a "screen shot" of one embodiment 
of a GUI for defining a playlist schedule within a studio 
console process in accordance with the invention. 30 
[0015] FIG. 4 is a "screen shot" of one embodiment 
of a GUI for displaying playback information and allow- 
ing selection of a playback channel within a user client 
process in accordance with the invention. 
[0016] FIG. 5A is a block diagram showing the client- 35 
host architecture for a capture session. 
[0017] FIG. 5B is a data flow diagram showing the da- 
ta flow for establishing a capture session. 
[0018] FIG. 5C is a data flow diagram showing the da- 
ta flow for recording during a capture session. 40 
[0019] FIG. 5D is a data flow diagram showing the da- 
ta flow for ending a capture session. 
[0020] FIG. 6A is a data flow diagram showing the da- 
ta flow architecture for playback of a multimedia data 
stream. 45 
[0021] FIG. 6B is a data flow diagram showing the da- 
ta flow for starting a playback session. 
[0022] FIG. 6C is a data flow diagram showing the da- 
ta flow for switching a playback channel. 
[0023] FIG. 6D is a data flow diagram showing the da- so 
ta flow for ending a playback session. 
[0024] Like reference numbers and designations in 
the various drawings indicate like elements. 
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DETAILED DESCRIPTION 

Overview 

[0025] The preferred embodiment of the invention al- 
lows a user connected to a specialized network having 
a "Radio" feature (e.g., the America Online network) to 
play back an audio broadcast that may be augmented 
with non-audio multimedia data, such as video and still 
images, URLs, text fields, etc. One aspect of the inven- 
tion includes a Studio Console Process executing on a 
content provider client system that allows such content 
to be created and scheduled. 

[0026] For example, the Studio Console Process en- 
ables a content provider to schedule a week's worth of 
prerecorded content that changes daily. The content 
provider uses a form in the Studio Console Process to 
assemble a "playlist" for each day. If the content provider 
then needs to conduct a live event on the Radio system, 
the content provider uses the Studio Console Process 
to override any existing playlist. When the live event is 
completed, the playlist resumes as originally scheduled. 
[0027] The data comprising a playlist may be pre-re- 
corded or live. The playlist data is compressed under 
the control of the Studio Console Process and transmit- 
ted to a host system as part of a "capture" process. The 
captured playlist data may then be "broadcast" to users 
who "tune in" to a "live multimedia show", or stored for 
later broadcast. (In this context, "broadcast" simply 
means transmittal of a data stream to a user who selects 
content to be played back on the user's client system). 
[0028] A user may initiate a form that displays availa- 
ble playlists for one or more "channels" of a host system, 
choose a selection from a playlist, and cause the select- 
ed item to be downloaded and played back by means 
of a "playback tool". The data stream corresponding to 
the selected item optionally may include embedded 
non-audio content, such as hypertext links to other 
forms, URLs to web pages, static images, or video im- 
ages. 

[0029] The host system includes a highly efficient dis- 
tribution system that allows a large number of users to 
rapidly access one or more channels of audio data aug- 
mented by non-audio data. The latency of access - the 
time between a request for playback of a particular 
channel and commencement of playback on a user cli- 
ent - is typically less than about 3 seconds, compared 
to tens of seconds for many prior art systems. 

System Architecture - Content Provider Ciient 

[0030] FIG. 1 A is block diagram of the preferred em- 
bodiment of the invention. Content to be broadcast is 
typically developed by a content provider utilizing a con- 
tent provider client 100. A Studio Console Process 102 
executes on the content provider client 1 00. The Studio 
Console Process 102 allows a content provider to define 
("author") a play list data stream to be uploaded to a 
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host 300 during a "capture" session for "broadcast" to 
users selecting the channel assigned to the playlist. (De- 
tails of a capture session are described below.) The 
playlist data stream includes audio content and may in- 
clude images or other data which may be inserted into s 
the data stream as the data is being compressed. In the 
preferred embodiment, the Studio Console Process 1 02 
communicates with a separate encoder tool 1 04 that re- 
sponds to and carries out the directions of the content 
provider input by means of the Studio Console Process 10 
1 02. In particular, the encoder tool 1 04 selects one of a 
plurality of encoder "plugins" 106 to perform necessary 
data compression of the multimedia content of the data 
stream. The encoder tool 104 also packages the com- 
pressed multimedia content into packets for transmis- 75 
siontothe host 300. In the preferred embodiment, audio 
data is given priority over non-audio data to reduce the 
likelihood of any objectionable interruption in audio play- 
back. In general, other types of data may be appended 
to audio packets as long as the total transmission packet 20 
{e.g., an Internet protocol packet) does not exceed a tar- 
get bit rate (e.g., 10 Kbps). 

[0031] Audio content may come from "live" sources to 
the content provider client 100, such as an input to a 
computer sound card from a microphone 108 or "line- 25 
in" source (e.g., an analog or digital audio playback de- 
vice such as an audio tape or CD player), or a direct 
input to the computer from a direct digital connection (e. 
g., CDROM player). Alternatively, audio content may 
come from pre-recorded ("canned") sound files, such as 30 
WAV and ART files, located on storage media 110 ac- 
cessible to the content provider client 100. 
[0032] Similarly, images (still or video) may come from 
"live" sources to the content provider client 100, such as 
video cameras. Still images can be from standard file 35 
formats, including ART, BMP, GIF or JPG (JPEG) for- 
mats. In the preferred embodiment, all such formats are 
re-compressed into a single format (ART) for the broad- 
cast data stream. 

[0033] One aspect of the invention is that a content 40 
provider may change an encoder plugin 1 06 "on-the-fly" 
to accommodate different content inputs as such inputs 
change. For example, an encoder plugin 1 06 particular- 
ly well-suited for speech may be used for a time (for ex- 
ample, while a conductor is explaining a music piece 45 
about to be played), and then an encoder plugin 106 
particularly well-suited for music may be switched in 
when the source material changes (for example, when 
the music piece is being played). 

[0034] FIG. 2 is a "screen shot" of one embodiment so 
of a graphical user interface (GUI) for defining a data 
stream within the Studio Console Process 1 02. The pre- 
ferred content definition GUI for the Studio Console 
Process 102 includes controls that allow the content 
provider to do at least the following in "authoring" a play- 55 
list entry: 

• Select an audio source 150 ("live" or "canned") for 



a data stream. 

• Define an audio target 1 52 for the data stream (e. 
g., a file name for storage on the content provider 
client 100 or on the host 300 for later broadcast, or 
a channel name for a live broadcast). 

• Select an encoder 154 for compressing the audio 
source data stream. The list of available encoders 
allows selection of varying degrees of compression, 
depending on the desired final sound quality and 
the nature of the audio source material (e.g., 
speech generally can be compressed more than 
music). Examples of such encoders include those 
available from Voxware, Inc. of Princeton, NJ. For 
example, the Voxware VR12 Speech Codec re- 
quires a bit rate of only 1 .5 Kbps for speech, while 
a music codec may require as much as 10 Kbps. 

• Define a "stream name" 156, which is a name for 
the data stream that is delivered to a user's play- 
back tool whenever playback is started for a partic- 
ular virtual channel. 

• Define a "stream description" 158 that provides a 
detailed description of the data stream that can be 
delivered to a user's playback tool on demand. For 
example, the description may contain rich-text - 
HTM L formatted text that may contain font and color 
information tags. 

• Define "caption text" 160, which is simple text that 
can appear within the data stream. In the preferred 
embodiment, when a playback tool receives a com- 
plete caption string, the caption string is forwarded 
to an auxiliary tool for display in a text field on a form, 
if the field exists. The caption text may be used for 
closed captioning or for other "headline" updates, 
and is preferably in "rich text format" (RTF). The 
caption text may also included hyperlinks. 

• Select image data 162 that can be delivered ap- 
pended to and interleaved with the audio data. The 
image data is inserted in the data stream wherever 
available space is found after the audio packets (a 
target bit rate for the data stream is set at authoring 
time) to expedite transfer to the client. When data 
is received at the playback tool, it is forwarded to 
an auxiliary tool for rendering. The original image 
data may be in any of a variety of formats, such as 
the well-known ART, BMP, GIF or JPG (JPEG) im- 
age formats, but is preferably transformed into a 
single multimedia ART format for broadcast. A 
number of images may be linked to form a "slide 
show". To save space in the data stream itself, a 
global ID reference to an image or video data may 
be delivered instead of an image itself. The global 
ID is passed by the user's playback tool to an aux- 
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iliary tool for rendering. This approach is useful if 
the referenced data resides on the client's system 
(i.e., the data was downloaded previously). Video 
data can also be delivered appended to and inter- 
leaved with the audio data. As with image data, vid- 
eo data is inserted in the data stream wherever 
available space is found after the audio packets. 
However, a significant amount of bandwidth is re- 
quired for video data, even for highly compressed 
video images, and thus should be limited for low- 
bandwidth users. When video data is received at 
the playback tool, it is forwarded to an auxiliary tool 
for rendering. 

• Select or define URLs 1 64 that can be delivered ap- 
pended to and interleaved with the audio data. 
When URLs are received at the playback tool, they 
forwarded to an auxiliary tool which attaches them 
to a button or image on a form (if one exists) dis- 
played to the user. When the button or image is se- 
lected by the user, the attached URL is activated in 
conventional fashion. 

[0035] The Studio Console Process 1 02 also may be 
used to schedule playlist content on a channel for an 
extended period of time. FIG. 3 is a "screen shot" of one 
embodiment of a GUI for defining a playlist schedule 
within the Studio Console Process 102. The preferred 
playlist definition GUI for the Studio Console Process 
1 02 includes controls that allow the content provider to 
do at least the following in scheduling a playlist: 

• Define a schedule 170 of start and stop times for 
each of a plurality of audio content files. 

• Select a channel 172 on which multimedia content 
will be made available to users. 

• Define a release date 1 74 for the playlist. 

• Check the overall start and stop times 1 76 and file 
characteristics 178 for the playlist content. 

System Architecture - User Client 

[0036] FIG. 1 A also shows a user client 200. In the 
preferred embodiment, a User Client Process 202 com- 
municates through a playback tool 204 across a network 
(e.g., the Internet) with the host 300 to access playlists 
and select a channel for playback. The User Client Proc- 
ess 202 responds to and carries out the directions of a 
user by means of the playback tool 204. In particular, 
the playback tool 204 selects one of a plurality of decod- 
er plugins 206 to perform necessary data decompres- 
sion of the multimedia content of a received data stream. 
The playback tool 204 also parses multimedia packets 
received from the host 300. In particular, the playback 
tool 204 processes all audio data internally, but forwards 



all non-audio data to one or more auxiliary tools 208, 
each of which can manage and render such data. 
[0037] In the preferred embodiment, while a data 
stream may contain all types of data, each particular 
5 calling form displayed by the User Client Process 202 
notifies the auxiliary tools 208 of the data that pertain to 
the form. That way, different forms can have different 
presentations for the same data stream. For example, 
one small form may only have start and stop buttons for 
10 the audio portion of the stream with no image box. The 
auxiliary tools 208 would not try to render any accom- 
panying image data. Another, larger form may have an 
image box that is updated by an auxiliary tool 208 when- 
ever a new image appears in the data stream. 
15 [0038] In the preferred embodiment, the user client 
process 202 provides the ability for a user to play back 
a particular playlist selection until a different channel is 
selected or the playback session is ended. Multimedia 
content may be delivered in a one-time transmission or 
20 may be continuously broadcast in a looping manner. In 
either event, the user is able to join an active broadcast 
at any point during its transmission. 
[0039] FIG. 4 is a "screen shot" of one embodiment 
of a GUI for displaying playback information and allow- 
25 jng selection of a playback channel within the User Cli- 
ent Process 202. (Details of a playback session are de- 
scribed below.) The preferred playback GUI includes 
controls that allow the user to do at least the following: 

30 • Display a playlist 400 of stream names for selecta- 
ble data streams. 

• Display a stream description 404 for a selected 
stream name. 

35 

• Display accompanying caption text 406. 

• Display accompanying graphics 408. 

40 • Display active link buttons 410 for accompanying 
URLs. 

• Include other desired or convenient controls, such 
a stop button 412. For example, if the user presses 

45 the stop button 412, the playback tool 204 should 
blank out the stream name, stream description, link 
button ; and caption text. The playback tool 204 
could also display a default name, such as "no sta- 
tion selected". The playback tool 204 may also 
so cause a blank image sent to the appropriate auxil- 
iary tool 208 if the user presses the stop button 41 2 
while an image is being rendered. A standard 
graphic can be displayed instead. 

55 System Architecture - Host Broadcast System 
Architecture 

[0040] Referring to FIG. 1A, a playlist of multimedia 
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content generated by a content provider client 100 is 
transferred in conventional fashion over a network (e.g., 
the Internet) to a host 300. The host 300 generally in- 
cludes one or more "front-end" Terminal Information 
Handlers (TIH) 302 that manage general information 
flow to and from the host 300 for multiple users. For ex- 
ample, on the America Online network, each TIH 302 
can manage about 63 concurrent users. A radio IN proc- 
ess 304 executing on the host 300 receives data from 
a content provider client 100 that is transmitted by 
means of "ri" (radio input) messages. The radio IN proc- 
ess 304 generally stores multimedia content as files in 
a storage device 306 that is accessible to the host 300 
for later broadcast or for archiving of the multimedia con- 
tent. However, the radio IN process 304 may also be 
used to directly transfer the received multimedia content 
to a radio OUT process 308 for broadcast to users re- 
questing playback. 

[0041] In accordance with a primary aspect of the in- 
vention, the radio OUT process 308 provides multiple 
data streams of multimedia content for access by users. 
In particular, the radio OUT process 308 may access 
multiple data streams from one or more storage devices 
306, or accept "live" feeds of multimedia content from 
the radio IN process 304 (e.g., a live interview or live 
reporting from the scene of a news event). Thus, the 
radio OUT process 308 gathers and assembles the data 
packets representing such multimedia content data 
streams into a "broader" multi-stream data flow. 
[0042] In order to provide a highly efficient distribution 
system that allows a large number of users to rapidly 
access one or more channels of multimedia data, the 
inventive system architecture provides a "fan out" mech- 
anism that includes a master broadcast process 312. 
The broadcast process 312 accepts the multi-stream 
data flow from the radio OUT process 31 0 and then dis- 
tributes the multi-stream data flow (shown as thick ar- 
rows in FIG. 1A) along with instances of itself 312 to 
essentially every terminal information handler 314 ac- 
cessible to the host 300. (Although only two instances 
of the broadcast process 312 and two TIHs 314 are 
shown, any number may be selected). Thus, the load of 
providing data streams is spread among a large number 
of Terminal Information Handlers 314. 
[0043] For example, in the America Online network, 
one instance of each broadcast process would be dis- 
tributed within an internal network to a "pod", each com- 
prising a large number of individual servers. Coupled to 
each pod in a ring are multiple TIHs 314. Executing on 
each pod is an instance of the broadcast process 312. 
which circulates the multi-stream data flow among all 
TIHs within the pod. In this manner, any one channel of 
multimedia data stream within the multi-stream data 
flow is available for transmittal to a user requesting play- 
back with very little delay. As noted above, in one em- 
bodiment of the invention, the access latency is typically 
less than about 3 seconds. 

[0044] FIG. 1 B is block diagram of a portion of an al- 



ternative embodiment of the invention. In this embodi- 
ment, the Terminal Information Handlers are configured 
hierarchically. A multi-stream data flow from a broadcast 
process 350 is transmitted to a top-level terminal front 
5 end processor (TFEP) 352 of conventional design, 
which controls multiple TIHs 354. The TFEP 352 then 
re-transmits the multi-stream data flow to dependent 
TIHs 354, reducing data traffic within the overall system 
compared to the ring architecture referenced above. 
Multiple user clients 356 may then access selected 
channels of the multi-stream data flow through the TIHs 
354. 

[0045] Once the multi-stream data flow content is 
available in the TIHs 314, any channel of the multi- 
stream data flow is available for transmittal to a user re- 
questing playback. To allow a user to select a particular 
channel, a tuner process 31 8 executing within the host 
300 is coupled to each TIH 314. The tuner process 318 
intercepts channel requests from users and commands 
the TIH 314 with which the user is in communication to 
deliver a particular multimedia data stream to that user 
from the multi-stream data flow. Thereafter, packets 
from that data stream are transmitted to the requesting 
user (see below for further discussion of playback ses- 
sions). 

[0046] An additional function of the tuner process 31 8 
is that it can "map" a channel name to a channel number. 
For internal efficiencies, each channel of the multi- 
stream data flow is given a channel number. However, 
it may be desirable to give one or more channel names 
to each channel number. Thus, channel "1 " may be as- 
signed the channel name of "The AOL Radio Hour" on 
one playback list form displayable to users for a partic- 
ular time slot, but be assigned the channel name of "The 
Motley Fool" on the same or another playback list form 
for a different time slot. Accordingly, in the preferred em- 
bodiment, the tuner process 318 maintains a map of 
channel names to channel numbers. The tuner process 
31 8 then maps an incoming channel name from a user's 
channel request to the corresponding channel number. 
That channel number is then used to select the corre- 
sponding data stream on the TIH 31 4 to transmit to the 
user. 

[0047] The inventive architecture may also be used in 
conjunction with conventional Internet multicast sys- 
tems by providing a connection 320 from the radio OUT 
process 308 to a multicast server system, in known fash- 
ion. This capability may be useful when a channel is ex- 
pected to have a relatively small audience which would 
not tax the "fan out" characteristics of the multicast sys- 
tem. However, for large "fan out" needs, the inventive 
architecture provides the advantages noted above. 

Capture Session 

[0048] FIG. 5A is a block diagram showing the client- 
host architecture for a capture session. A content pro- 
vider is provided with the Studio Console Process 102, 
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encoder tool 104, and encoder plugins 106 described 
above, which may be considered to be a single "capture 
tool" 502 executing on a content provider client 1 00. The 
capture tool 502 communicates with the host 300 over 
a network through a Send function 504, which takes 
care of the details of data transmission in known fashion. 
The host 300 communicates with the capture tool 502 
through a Terminal Information Handler (TIH) 302 ; as 
described above. The capture process requires only 
one host process, the radio IN process 304, whose func- 
tion is to receive data from a content provider that is 
transmitted by means of "ri" (radio input) messages. The 
radio IN process 304 stores multimedia content as files 
in a storage device 306 that are accessible to the host 
300 for later broadcast. There are three phases of a cap- 
ture session: Starting the capture session, Recording, 
and Ending the capture session. 
[0049] For a live input (e.g., a microphone capture), 
initiating a capture session will start recording, com- 
pressing the multimedia data using the selected encod- 
er plugin 106, packetizing the compressed multimedia 
data as a data stream, and uploading the data stream 
to the host 300. Since the data is compressed and trans- 
mitted while the "live" data (e.g., voice from a micro- 
phone) is being recorded, the author has no ability to 
edit and review the content. This option will most likely 
be used for unrehearsed content. For pre-recorded in- 
put {e.g., a WAV file), initiating a capture session will 
start compressing the multimedia data using the select- 
ed encoder plugin 106, packetizing the compressed 
multimedia data as a data stream, and uploading the 
data stream to the host 300. Because the input data is 
file based, the author has the ability to edit and review 
content off-line before submitting it to the host 300. 
[0050] FIG. 5B is a data flow diagram showing the da- 
ta flow for establishing a capture session (the represen- 
tation of the Send function 504 and TIH 302 from FIG. 
5 have been omitted for clarity). To establish a capture 
session, the user invokes a "connect" function 506 in a 
form 508 of the capture tool 502, which uploads a 
CLIENT_CONNECT message 510 to the radio IN proc- 
ess 304 within the host 300. The radio IN process 304 
returns the same message 512 to acknowledge that a 
connection has been established. 
[0051] FIG. 5C is a data flow diagram showing the da- 
ta flow for recording during a capture session. After the 
host 300 has been informed that the content provider 
client 100 will be sending data, the capture tool 502 in- 
itiates transfer of multimedia content with an "rc" (radio 
control) START_STREAM message 514. The radio IN 
process 304 returns the same message 51 6 to acknowl- 
edge the start of data transmission and opens 515 a file 
to store the data stream. The initialization message is 
then followed by "ri" (radio input) DATA messages 518-1 
to 51 8-nf rom the capture tool 502. The DATA messages 
contain the audio data and any supplemental data ap- 
pended to the audio data. At the end of the data stream, 
the capture tool 502 sends an "rc" (radio control) 



END_STREAM message 520. The radio IN process 304 
returns the same message 522 to acknowledge the end 
of data transmission and closes 523 the data file used 
to store the data stream. 
5 [0052] FIG. 5D is a data flow diagram showing the da- 
ta flow for ending a capture session. The capture ses- 
sion is stopped by closing the open form 508 of the cap- 
ture tool 502 or by pressing the appropriate cancel con- 
trol. When this happens, the capture tool 502 sends an 
10 "rc" (radio control) CLIENT_DISCONNECT message 
524 to the radio IN process 304. The radio IN process 
304 returns the same message 526 to acknowledge that 
the connection has been terminated. When this occurs, 
the capture tool 502 is shutdown by the content provider 
15 client 100. 

Playback Session 

[0053] FIG . 6A is a data flow diagram showing the da- 
20 ta flow architecture for playback of a multimedia data 
stream. A user is provided with a user client process 
202, playback tool 204, and decoder plugins 206 as de- 
scribed above, which may be considered to be a single 
"playback tool" executing on the user client 200. The 
25 playback tool includes a playback form 602 to accept 
user selection of a channel. The channel selected is 
communicated to the processes described above with 
respect to FIG. 1A, which may be considered to be a 
single "broadcast system" 604 from the user's perspec- 
30 tive. 

[0054] The broadcast system 604 manages the deliv- 
ery of radio control messages ("rc") and radio broadcast 
("rb") data to the user client 200 through a Terminal In- 
formation Handler, as described above. There are four 

35 phases of playback sessions: Start Playback, Playback, 
Switching Channels, and Ending Playback. 
[0055] FIG . 6B is a data flow diagram showing the da- 
ta flow for starting a playback session. To establish a 
playback session, the user uses the playback tool to 

40 download a selection form from the host 300. In partic- 
ular, the broadcast system 604 will have initialized the 
playback form 602 with the available channels. A chan- 
nel is selected from the playback form 602, and the play- 
back tool notifies the broadcast system 604 of the se- 

45 lected channel through a CHANNEL REQUEST com- 
mand message 606. 

[0056] Once the broadcast system 604 has been in- 
formed that the user client 200 has selected a particular 
radio channel for playback (i.e., the tuner process 316 

50 receives an "rw" token with a channel name), the broad- 
cast system 604 initiates the broadcast with a "rc" (radio 
control) START_CMD message 608. This initialization 
message is immediately followed by "rb" (radio broad- 
cast) data messages 610. The data messages 61 2 pref- 

55 erably alternate header information and multimedia da- 
ta. In the preferred embodiment, an identical header to- 
ken is repeated with every data transmission so that us- 
ers can join in the broadcast at any particular moment. 
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The final "rb" data packet 614 transmitted contains an 
"end-of-file" (EOF) identifier. In the preferred embodi- 
ment, it the playback content loops, the first data header 
will be transmitted again, and the broadcast will restart. 
Otherwise, a special "rc" STOP_PLAY_0 message (not 
shown) is sent to shut down that particular channel. 
[0057] FIG. 6C is a data flow diagram showing the da- 
ta flowfor switching a playback channel. The basic proc- 
ess is similar tothe process described for FIG. 6B. How- 
ever, when a program is playing, the user can request 
a different program using the playback form 602. The 
playback tool notifies the broadcast system 604 of the 
new selected channel through a channel request mes- 
sage 606'. The broadcast system 604 then initiates the 
new broadcast with a "rc" (radio control) START_CMD 
message 608'. This initialization message is immediate- 
ly followed by "rb" (radio broadcast) data messages 61 0' 
for the new channel. Whenever a new channel is start- 
ed, the stream name and stream description is sent to 
the appropriate auxiliary tool 208 for display if provided 
by the playback form 602. 

[0058] FIG. 6D is a data flow diagram showing the da- 
ta flowfor ending a playback session. The playback ses- 
sion is stopped by closing the open playback form 602 
or by pressing the appropriate cancel control. When this 
happens, a TERMINATE SESSION command message 
616 is sent to the broadcast system 604 to force a 
STOP_PLAY_0 618 message to be sent back to the us- 
er client 200. When this occurs, the playbacktool is shut- 
down. 

Computer Implementation 

[0059] The invention may be implemented in hard- 
ware or software, or a combination of both. However, 
preferably, the invention is implemented by means of a 
computer program executing on one or more program- 
mable systems each comprising at least one processor, 
a data storage system (including volatile and non-vola- 
tile memory and/or storage elements), at least one input 
device, and at least one output device. Program code is 
applied to input data to perform the functions described 
herein and generate output information. The output in- 
formation is applied to one or more output devices, in 
known fashion. 

[0060] Each such program may be implemented in 
any desired computer language (including machine, as- 
sembly, high level procedural, or object oriented pro- 
gramming languages) to communicate with a computer 
system. In any case, the language may be a compiled 
or interpreted language. 

[0061] Each such computer program is preferably 
stored on a storage media or device (e.g., ROM or mag- 
netic media) readable by a general or special purpose 
programmable computer, for configuring and operating 
the computer when the storage media or device is read 
by the computer to perform the procedures described 
herein. The inventive system may also be considered to 



be implemented as a computer-readable storage medi- 
um, configured with a computer program, where the 
storage medium so configured causes a computer toop- 
erate in a specific and predefined manner to perform the 

5 functions described herein. 

[0062] A number of embodiments of the present in- 
vention have been described. Nevertheless, it will be un- 
derstood that various modifications may be made with- 
out departing from the spirit and scope of the invention. 

10 For example, while specific controls have been shown 
in FIGS. 2-4, other controls may be used to provide sim- 
ilar functionality. Further, while FIGS. 5A-5D and 6A-6D 
show preferred messaging and data flow protocols, oth- 
er messaging and data flow protocols may be used to 

15 provide similar functionality. Accordingly, other embod- 
iments are within the scope of the following claims. 



Claims 

20 

1 . A system for playback of live and pre-recorded mul- 
timedia data in real-time over a large scale commu- 
nication network, including: 

25 (a) a computer system having a plurality of ter- 

minal information handlers for managing gen- 
eral information flow to and from a plurality of 
users; 

30 (b) an output process for assembling multiple 

multimedia data streams for distribution; 

(c) at least one broadcast process, in commu- 
nication with the output process, for distributing 

35 the assembled multiple multimedia data 

streams to each of the terminal information 
handlers; and 

(d) a selector process, in communication with 
40 the terminal information handlers, for receiving 

a channel request from a user through an ter- 
minal information handler associated with the 
user, mapping the channel request to a corre- 
sponding one of the multiple multimedia data 
45 streams, and enabling transmission of the cor- 

responding one multimedia data stream to the 
user through the associated terminal informa- 
tion handler. 

50 2. The system of claim 1, further including an input 
process for receiving multimedia data streams for 
distribution. 

3. The system of claim 1 , further including at least one 
55 storage device for storing multimedia data streams 

for later transmission. 

4. A method for playback of live and pre-recorded mul- 
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timedia data in real-time over a large scale commu- 
nication network, including the steps of: 

(a) providing a plurality of terminal information 
handlers for managing general information flow 5 
to and from a plurality of users; 

(b) assembling multiple multimedia data 
streams for distribution; 

10 

(c) distributing the assembled multiple multime- 
dia data streams to each of the terminal infor- 
mation handlers; and 

(d) receiving a channel request from a user ?5 
through an terminal information handler asso- 
ciated with the user, mapping the channel re- 
quest to a corresponding one of the multiple 
multimedia data streams, and enabling trans- 
mission of the corresponding one multimedia 20 
data stream to the user through the associated 
terminal information handler. 

5. The method of claim 4, further including the step of 
receiving multimedia data streams for distribution. 25 

6. The method of claim 4, further including the step of 
storing multimedia data streams for later transmis- 
sion. 
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